Mobile devices such as mobile phones, personal digital/data assistants, (“PDA”), two-way pagers, etc. are relatively inexpensive, have become commonplace, and are available to most consumers. These mobile network devices can be wireless or wired mobile devices.
Such mobile devices are typically limited to small physical size, light weights and corresponding small display screen sizes. These mobile devices have a number of constraints including limited processing power, limited memory, limited battery life, a limited number of buttons on a user interface, etc.
The larger a processor in a mobile device, the larger the size and weight the device will be. The more memory in a device the more expensive it will be. Faster processors, more memory and color displays consume more battery power.
Content and service providers who provide content and services via mobile devices have to balance the physical constraints of such mobile devices along with the ability to provide applications and content that consumers actually want, and are willing to pay for. The content and services have to be provided to mobile devices in a format that is usable on the mobile device and have to be provided quickly since most users of mobile devices pay for content and services by the minute.
There are relatively few applications that have been created to be used on mobile devices that provide content in a format useable on the mobile devices. The applications that do exist include text-based micro-browsers for delivering real-time stock quotes, access to news, sports scores, weather forecasts, text-based electronic commerce applications and other types of text-based applications.
There are a number of problems associated with developing applications for mobile devices. One problem is that virtually every mobile device has a unique hardware platform. An application written for one mobile device hardware platform won't work on another hardware platform for another mobile device.
To help overcome this problem for devices in general, Sun Microsystems of Mountain View, Calif., developed the Java programming language. Java is a high-level programming language that was designed to be platform-neutral (i.e., it can be run on virtually any hardware platform). Java programs are compiled into byte-code and run in a special software environment known as a “virtual machine.” This and other characteristics of Java make it a useful language for programming a large number of different types of applications for mobile devices. Java is typically used for programming small applications, called Java “applets.”
When Java applets are downloaded onto a device they are executed by a Java virtual machine in a secure “sandbox.” A sandbox is Java virtual machine security area for downloaded (i.e., remote or untrusted) applets. The sandbox is an area in which such applets are confined and prevented from accessing certain data and resources (e.g., system resources and data). Confinement to the sandbox prevents downloaded applets from carrying out potentially dangerous or malicious operations on the device. Applets have to “play” inside the sandbox, and any attempt to “escape” is thwarted by a Java security manager.
However, the full version of the Java programming language was too large to be used on mobile devices with constrained resources. When Sun Microsystems developed the second version of Java, it was split into three editions. The three editions include micro version, Java 2 Micro Edition (“J2ME”) for small mobile devices, a standard version, Java 2 Standard Edition (“J2SE”) for desktop or other larger devices, and an enterprise version, Java 2 Enterprise Edition (“J2EE”) for multi-tier networking applications.
J2ME is cross-platform programming language that can be embedded into small application environments such as mobile phones, PDAs, two-way pagers, etc. The J2ME environment can be implemented specifically for an individual device through a Connected Limited Device Configuration (“CLDC”). This configuration is typically used for mobile devices that are battery operated, memory constrained, processor limited, low bandwidth, and provide high latency, network connectivity. The CLDC defines the basic libraries that must be present in a J2ME implementation so that a Java virtual machine can run the application across different hardware platforms and environments.
The J2ME Mobile Information Device Profile (“MIDP”) is a set of Java Application Programming Interfaces (“API”) that provides the runtime environment for J2ME applications using the CLDC. The MIDP manages applications, user interfaces, networking and input/output for the mobile device.
J2ME applications that conform to the MIDP are called “MIDlets” (instead of an applet). A group of related MIDlets can be grouped together to create a MIDlet Suite that can be used to provide a more complex application to a mobile device.
J2ME MIDlets are being used on mobile devices to provide platform independent applications on mobile devices such as games, audio and video players, site-specific applications (e.g., dynamic stock quote banner, dynamic news banner, etc.) device specific applications (e.g., new ring tones, new fonts, new graphical look-and-feel, etc.) and many other types of applications.
There are a number of problems associated with using MIDlets and MIDlet Suites on a mobile device. One problem is that for security reasons, one MIDlet Suite cannot launch another MIDlet Suite (i.e., act as its handler). Since the CLDC and MIDP does not define or use a Java security manager (i.e., a security manager is typically too big and complex for small devices), the interactions of MIDlets is limited to MIDlets packaged together in the same MIDlet Suite. However, the MIDP specification does not explicitly prohibit one MIDlet Suite from launching another MIDlet Suite.
Another problem is that a MIDlet in a MIDlet Suite cannot accept input data from, or cannot provide output data to, another MIDlet in another MIDlet Suite because a MIDlet Suite is executed in its own sandbox. This limits the type of MIDlet applications that can be created for a mobile device and prevents the ability to allow interaction between MIDlets or MIDlet Suites that have already been created. Another problem is that a MIDlet Suite cannot accept input data from, or provide output data to other applications on the mobile device (i.e., non-MIDlet applications).
Thus, it is desirable to allow a J2ME MIDlet in a MIDlet Suite to accept data from, and provide data to, other MIDlets in other MIDlet Suites on a mobile device. It is also desirable to allow a MIDlet to accept data from, and provide data to, other non-MIDlet applications on a mobile device.